profile
viewpoint
Marcos Cáceres marcoscaceres Mozilla Around the world, around the world... https://marcosc.com Standards Engineer at @mozilla working on @w3c specs and future web stuff.

highlightjs/highlight.js 16823

Javascript syntax highlighter

adrianhopebailie/web-monetization 16

Web Monetization Explainer and Specification for submission to the WICG

adrianhopebailie/modal-window 8

A proposed Web API to invoke a modal window dialogue

highlightjs/highlightjs-vue 5

highlight.js syntax definition for Vue.js

JSWorkshops/fundamentals 4

Fundamentals of modern ECMAScript

Geonovum/respec 1

A tool for creating technical documents and web standards. Geonovum fork to modify respec for own use.

highlightjs/highlight-dylan 1

highlight.js support for the Dylan language

highlightjs/highlightjs-robot 1

Robot Framework

highlightjs/highlightjs-structured-text 1

Highlightjs Structured Text language support IEC 61131-3

marcoscaceres/adlib.js 1

A prototype reference implementation of Web MIDI API

pull request commentw3c/screen-wake-lock

Add a Changes section

I'm ok with this just to get us over the line (so big thanks @xfq for putting it together!). However, it will be a quite a chore to maintain in the future. After we publish, I can add the rs-changelog and filter out all the editorial/chore stuff.

xfq

comment created time in 13 hours

Pull request review commentw3c/screen-wake-lock

Add a Changes section

 <h2>         to this work.       </p>     </section>+    <section class="appendix informative" id="changes">+      <h2>+        Changes+      </h2>+      <p>This section documents the changes since previous publications.</p>+      <section id="changes-20171214">+        <h2>Changes since the 14 December 2017 CR</h2>+        <ul>+          <li>Convert the document to purely screen wake lock, and move system lock to a new specification.</li>+          <li>Rewrite user-visible API.</li>+          <li>Add an <a>if aborted</a> step to <code>WakeLock.request()</code> to deal with hidden documents.</li>+          <li>Add an IDL Index.</li>+          <li>Remove duplicate normative statements.</li>+          <li>Modernize the examples.</li>+          <li>Use internal slots instead of prose.</li>+          <li>Add info on when the user agent may <a>release a wake lock</a>.</li>+          <li>Handle document visibility.</li>+          <li>Make WakeLock constructable.</li>
          <li>Make {{ScreenWakeLock}} constructable.</li>
xfq

comment created time in 13 hours

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++

Isn't there some mechanism that can restrict access to APIs from third-party scripts?

No, unfortunately.

Use of unscrutinized third party script falls into a different class of threats, like disgruntled developer risk, that affect all powerful APIs and are not specific to the web platform.

Right, I think this is where we get into the fundamental philosophical differences in our communities: Mozilla folks are hesitant to add anything to the platform that allow a "disgruntled developer" level attack. Why we have no BlueTooth, MIDI, etc. etc... so, in a sense they are specific to the web platform in as far as Mozilla (and Apple) have not allowed shipped these kinds of APIs for this reason.

That's not to say it's a show stopper - but it gives us a point at which we can ask, "what's this thing trying to do?"

ewilligers

comment created time in 13 hours

issue closedw3c/manifest-app-info

Publish the document to TR

So that https://w3c.github.io/manifest-app-info works

closed time in a day

kenchris

create barnchw3c/manifest-app-info

branch : changelog

created branch time in a day

create barnchmarcoscaceres/respec.org

branch : changelog

created branch time in a day

created tagw3c/manifest-app-info

tagFPWD

Web App Manifest - Application Information

created time in a day

delete branch w3c/manifest-app-info

delete branch : autopub

delete time in a day

pull request commentw3c/manifest-app-info

chore: set up autopublish

@siusin if everything looks good to you, please feel free too merge :) Everything should work from there 🤞

marcoscaceres

comment created time in 2 days

push eventw3c/manifest-app-info

Marcos Cáceres

commit sha 36e03519bdf6292115e2c4f2bbfa294ba2f9b7e3

chore: fix ReSpec config to use main branch

view details

Marcos Cáceres

commit sha 2fc2e61b8406d1456ba5e83cfcf32217e7b31d8d

Merge branch 'main' into autopub

view details

push time in 2 days

push eventw3c/manifest-app-info

Marcos Cáceres

commit sha 36e03519bdf6292115e2c4f2bbfa294ba2f9b7e3

chore: fix ReSpec config to use main branch

view details

push time in 2 days

push eventw3c/manifest-app-info

Marcos Cáceres

commit sha 99cc47d19a50ee962442ac24475a304a2651e280

Update action.yml

view details

push time in 2 days

pull request commentw3c/manifest-app-info

chore: set up autopublish

@siusin, can you confirm the IPR bot is set up properly? I don't see it in the branch protection list in settings?

marcoscaceres

comment created time in 2 days

push eventw3c/manifest-app-info

siusin

commit sha 3e8c2fb8b13928c310230dabe0e0de91b8a0b461

update specStatus

view details

siusin

commit sha bbf93a07bcc9c202c64b7329b8556d7b5aef6268

update specStatus

view details

Marcos Cáceres

commit sha 9b13932224e06c906abaa3109ef16a5da559530a

Editorial: remove extra "this" closes #17

view details

Marcos Cáceres

commit sha 17a0d4bb0616506e741ad32d43a2252605eccde9

Merge branch 'main' into autopub

view details

push time in 2 days

push eventw3c/manifest-app-info

Marcos Cáceres

commit sha 9b13932224e06c906abaa3109ef16a5da559530a

Editorial: remove extra "this" closes #17

view details

push time in 2 days

issue closedw3c/manifest-app-info

Typo? at §2

At section 2, after Example-1 "As the application manifest is JSON, this the members of this specification are of the types object, array, and string as defined in The JSON Data Interchange Format."

I am far from being good at English, but wouldn't there be one extra "this"?

closed time in 2 days

ntounsi

delete branch w3c/manifest-app-info

delete branch : gh-pages

delete time in 2 days

issue commentw3c/manifest-app-info

Typo? at §2

You are right. Typo :) Will fix.

ntounsi

comment created time in 2 days

issue closedw3c/manifest-app-info

Ok to drop "main" branch?

So, turns out we are actually going to need "gh-pages" branch, because the W3C auto-pub service needs to access the ECHINDA at the root of this repo over HTTPS... so, we might just treat "gh-pages" as our default branch.

closed time in 2 days

marcoscaceres

issue commentw3c/manifest-app-info

Ok to drop "main" branch?

Github fixed this.

marcoscaceres

comment created time in 2 days

pull request commentw3c/manifest-app-info

chore: set up autopublish

Good news! looks like Github now allows main to serve the main branch... just set it up and works! So, no need to wait.

marcoscaceres

comment created time in 2 days

issue commentw3c/screen-wake-lock

New shortname

@xfq, how we looking for for just getting screen-wake-lock on TR again?

marcoscaceres

comment created time in 2 days

issue closedw3c/screen-wake-lock

Add "geolocation" wake lock

@tomayac is interested in this for the GeolocationSensor.

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/run-minimized-with-extended-execution

Windows also has special API for geolocation as there can

  • Only be one lock at a given time
  • Regular CPU "system" lock has a time limit when the device is running on battery

We could also spec that the lock would be rejected if the same global scope doesn't have an active GeolocationSensor - I think that makes sense.

This might require some spec changes in the GeolocationSensor spec as well.

Up for speccing this @tomayac ?

closed time in 2 days

kenchris

issue commentw3c/screen-wake-lock

Add "geolocation" wake lock

Closing, as this is now out of scope for this spec. @tomayac, should we spin this issue up somewhere else? I wonder if we should just spin this up directly in http://github.com/w3c/geolocation-api/ ?

kenchris

comment created time in 2 days

delete branch w3c/screen-wake-lock

delete branch : permissions

delete time in 2 days

push eventw3c/screen-wake-lock

Marcos Cáceres

commit sha 854cd93d1b8a467afe6cf1687c6c48d9f188ccfe

Editorial: s/Feature Policy/Permissions Policy (#266)

view details

push time in 2 days

PR merged w3c/screen-wake-lock

Editorial: s/Feature Policy/Permissions Policy

Closes #264

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->


<a href="https://pr-preview.s3.amazonaws.com/w3c/screen-wake-lock/pull/266.html" title="Last updated on Aug 4, 2020, 2:12 AM UTC (4e7231f)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/screen-wake-lock/266/0cef480...4e7231f.html" title="Last updated on Aug 4, 2020, 2:12 AM UTC (4e7231f)">Diff</a>

+22 -30

5 comments

1 changed file

marcoscaceres

pr closed time in 2 days

issue closedw3c/screen-wake-lock

Update the reference to Feature Policy

https://w3c.github.io/screen-wake-lock/#policy-control

The spec has been renamed: w3c/webappsec-permissions-policy#379

closed time in 2 days

xfq

pull request commentw3c/screen-wake-lock

Editorial: s/Feature Policy/Permissions Policy

CI issue is #262

marcoscaceres

comment created time in 2 days

push eventw3c/web-share

plehegar

commit sha ea220bac7b2b847647918745e7f7491f02f4e856

chore: update repo-type in w3c.json

view details

Marcos Cáceres

commit sha 47476601058fcbc9e59206aa983a3393a9d4ef77

Editorial: use new HTML activation model (#135) This is refactor to use HTML's new activation model. The api currently uses transient activation.

view details

Yves Lafon

commit sha de985b7c2c7cc5dc59b7ff7114160e352a678ffc

[chore] updating w3c.json to new group and purpose

view details

Yves Lafon

commit sha 1589731080e09b9c7d485e54340ba66bc3ae1be0

added WG disclosure page

view details

Matt Giuca

commit sha 2ed0b468aacf7a4e3e351f25f114e9cb2fbef009

Added Eric Willigers as co-editor. (#139) Closes #138.

view details

Kagami Sascha Rosylight

commit sha 229b07b1d5c3e953222d376f30464f103ca45829

chore: Link `this` to Web IDL (#140)

view details

Marcos Cáceres

commit sha 1cc018ce05be012cf06754707d97f3a8f0ce5689

chore: 'present' xref does not exist (#147)

view details

Eric Willigers

commit sha 5f837a9b3c43dfbf4a30c945934f4407a6e0cbd0

Accessibility considerations (#146) Add section reminding implementors to follow OS level accessibility guidelines. resolves #145

view details

Joshua Bell

commit sha 3801fcf710a91e9861fc6be6a0f2fc0b180618b3

Initial take on Security/Privacy self-review (#150) Co-authored-by: Marcos Cáceres <marcos@marcosc.com> Closes #149

view details

Marcos Cáceres

commit sha f61564925e201e996b565f880d510e29f5d9634a

Add the ability to share files (#133) Add a `files` member to ShareData dictionary. Co-authored-by: Eric Willigers <ericwilligers@chromium.org>

view details

Marcos Cáceres

commit sha 8090cc7cc94235ecefc0c14d448f468708276845

chore: use ReSpec IDL syntax (#154)

view details

Eric Willigers

commit sha 6c8c25a77de0badfcad1a0494ceb193fb25b9998

chore: Clarify reason for choosing USVString (#153) We use USVString members as they are not allowed to contain surrogate code points. closes #152 Co-authored-by: Eric Willigers <ericwilligers@chromium.org>

view details

Marcos Cáceres

commit sha c7e251de2035f9c88c2c2267c9dcd476baadb5bc

chore: export 'share target' (#158)

view details

Marcos Cáceres

commit sha 7c2431d82489b9735627d8814a606e33efd68869

chore: tidy (#157)

view details

Marcos Cáceres

commit sha c73d0bf5ea988b2d43b7ac1c7dd5d0f5d3e02b50

chore: enable autopublish (#160)

view details

Marcos Cáceres

commit sha 4ef0a2dda91ae9ed00963c88c1f2fd36dcaa5dcc

chore: run when merging on master (#161)

view details

Marcos Cáceres

commit sha f62dc29a149dbeac0ba30046bab5ae8451407255

BREAKING CHANGE: make share() consume user activation (#137)

view details

Eric Willigers

commit sha 2ef967abba6cb1e0b114b4c3729229d663ebc97f

Introduce "web-share" feature policy (#166) resolves #151

view details

Marcos Cáceres

commit sha 479319b248eb0097fd9074fb897d6650d09e246a

Editorial: s/feature-policy/permissions-policy (#171)

view details

Marcos Cáceres

commit sha aeb208c5c0eebe68cd1f0fbe7314cd49c0ad8012

Use a sequence for files (#170)

view details

push time in 2 days

delete branch w3c/webidl2.js

delete branch : dependabot/npm_and_yarn/elliptic-6.5.3

delete time in 2 days

push eventw3c/webidl2.js

dependabot[bot]

commit sha ba45a5c9bdd29e0df9d291e8f22effdb9432a9cc

chore(deps): bump elliptic from 6.5.2 to 6.5.3 (#485) Bumps [elliptic](https://github.com/indutny/elliptic) from 6.5.2 to 6.5.3. - [Release notes](https://github.com/indutny/elliptic/releases) - [Commits](https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

push time in 2 days

PR merged w3c/webidl2.js

chore(deps): bump elliptic from 6.5.2 to 6.5.3 dependencies

Bumps elliptic from 6.5.2 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li>See full diff in <a href="https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 2 days

push eventweb-platform-tests/wpt

Christian Liebel

commit sha 28e07e1b5131b22e8237136bc14aad1a907d076a

[appmanifest] add basic tests for start_url (#24574)

view details

push time in 2 days

PR merged web-platform-tests/wpt

Reviewers
[appmanifest] add basic tests for start_url appmanifest wg-webapps
+51 -0

6 comments

8 changed files

christianliebel

pr closed time in 2 days

issue commentw3c/dap-charter

DASWG: Drop Battery API for privacy and lack of implementer support

Those are good suggestions @tomayac. I'm still hopeful we can see actual cases where something like "prefers-reduced-energy" would help... like what would added/removed/changed. We talked about video above, so we would need to figure out if it could help there.... like, if <video>'s element could be used with <source media="(prefers-reduced-energy: yep)" src="video">.

tantek

comment created time in 2 days

push eventw3c/web-share

Marcos Cáceres

commit sha aeb208c5c0eebe68cd1f0fbe7314cd49c0ad8012

Use a sequence for files (#170)

view details

push time in 2 days

PR merged w3c/web-share

User a sequence for files

Closes #165

For normative changes, the following tasks have been completed:

  • [X] Modified Web platform tests - happens automatically.

Implementation commitment:

  • [ ] WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
  • [X] Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=1112600)
  • [ ] Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=1635700)
+1 -1

0 comment

1 changed file

marcoscaceres

pr closed time in 2 days

issue closedw3c/web-share

files members should be a sequence, not a FrozenArray

When passing dictionaries as arguments, FrozenArray doesn't make much sense, as:

  1. dictionaries are passed by value
  2. it implies that dictionary.files = Array.freeze([...files]);, which is really what is mean there.

Related discussion https://github.com/heycam/webidl/issues/900

closed time in 2 days

marcoscaceres

issue openedw3c/screen-wake-lock

Set up ReSpec autopublish

See: https://github.com/w3c/respec-w3c-auto-publish

What's nice is that we get the validation errors directly in Github, without needing to go to TravisCI.

created time in 2 days

pull request commentw3c/screen-wake-lock

Editorial: s/Feature Policy/Permissions Policy

Thanks for the additional check @rakuco. Hopefully all good to go!

marcoscaceres

comment created time in 2 days

push eventw3c/web-share

Marcos Cáceres

commit sha 479319b248eb0097fd9074fb897d6650d09e246a

Editorial: s/feature-policy/permissions-policy (#171)

view details

Marcos Cáceres

commit sha ba20c73b6323a94129f8d966eee8e6e7d116d8fd

Merge branch 'master' into frozen

view details

push time in 2 days

push eventw3c/screen-wake-lock

Marcos Cáceres

commit sha 4e7231fa6d3ef82c00edfe8ff33fc791d28a06dc

tidy

view details

push time in 2 days

push eventw3c/screen-wake-lock

Marcos Cáceres

commit sha a2ea79cc00626886ba3f9a9d2f1ec6c000919358

Fix markup

view details

push time in 2 days

push eventw3c/screen-wake-lock

Marcos Cáceres

commit sha cc441bace9be6c308e256c235d2c172ef176770d

Review feedback

view details

push time in 2 days

PR opened w3c/web-share

Editorial: s/feature-policy/permissions-policy
+1 -1

0 comment

1 changed file

pr created time in 2 days

create barnchw3c/web-share

branch : pemissions_policy

created branch time in 2 days

delete branch w3c/payment-request

delete branch : cedex

delete time in 2 days

push eventw3c/payment-request

Marcos Cáceres

commit sha f5da228179e28880c6ce8a7da6b37ab7a858b3ef

Editorial: clarify what sorting code is a bit more (#921)

view details

push time in 2 days

PR merged w3c/payment-request

Reviewers
Editorial: clarify what sorting code is a bit more

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->


<a href="https://pr-preview.s3.amazonaws.com/w3c/payment-request/pull/921.html" title="Last updated on Jul 30, 2020, 7:38 AM UTC (ecc70aa)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/payment-request/921/28dd285...ecc70aa.html" title="Last updated on Jul 30, 2020, 7:38 AM UTC (ecc70aa)">Diff</a>

+1 -1

0 comment

1 changed file

marcoscaceres

pr closed time in 2 days

PR opened w3c/web-share

User a sequence for files

Closes #165

For normative changes, the following tasks have been completed:

  • [X] Modified Web platform tests - happens automatically.

Implementation commitment:

  • [ ] WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
  • [ ] Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
  • [ ] Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)
+1 -1

0 comment

1 changed file

pr created time in 2 days

push eventw3c/web-share

Marcos Cáceres

commit sha fe118576f192279dda20812299b4811eb11def56

User a sequence for files

view details

push time in 2 days

create barnchw3c/web-share

branch : frozen

created branch time in 2 days

issue commentw3c/manifest

Related applications members (at risk?)

If the PWA knows that the native app is installed, it can just switch into that app, but if not, it can ask the user to install it.

This sounds a lot like "Smart App Banners" from Apple: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html

Not saying we should use that, as it's very iOS specific - but just sounds quite similar.

Just so it's a bit more clear, is the use case then for GIRA to only work on an installed web application? That is, does a user first need to install the PWA, then when they open the PWA they are told to use/install the native app instead?

marcoscaceres

comment created time in 2 days

Pull request review commentWICG/raw-sockets

UDP sockets in explainer

 let writableStream = tcpSocket.writable; tcpSocket.close(); ``` +To simplify security analysis, an API for listening for incoming connections is not yet being proposed.+ ## UDP++To simplify security analysis, the initial proposal only supports cases where the web app initiates communication with a remote host.++```+const options = {+    remoteAddress: 'example.com',+    remotePort: 7+};+navigator.openUDPSocket(options).then(udpSocket => { ... }).else(error => { ... });+```++The UDP socket can use events to indicate when a packet can be sent or received. No send event is generated until after a packet has been sent.

Any reason events were chosen over a stream?

ewilligers

comment created time in 2 days

Pull request review commentWICG/raw-sockets

UDP sockets in explainer

 let writableStream = tcpSocket.writable; tcpSocket.close(); ``` +To simplify security analysis, an API for listening for incoming connections is not yet being proposed.+ ## UDP++To simplify security analysis, the initial proposal only supports cases where the web app initiates communication with a remote host.++```+const options = {+    remoteAddress: 'example.com',+    remotePort: 7+};+navigator.openUDPSocket(options).then(udpSocket => { ... }).else(error => { ... });

Nit: just assume top-level await for examples...

try {
  const udpSocket = await navigator.openUDPSocket(options);
  doStuffWith(udpSocket);
} catch (err) {
  // handle error
}
ewilligers

comment created time in 2 days

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++++### Threat++A web app might initiate connections without the user realizing.++### Mitigation++When initiating a connection, the user agent would show some UI.++The user can be asked to specify a hostname or IP address, with an option to permit future connections to this host.

Agree... this is the challenging bit. How do you explain what is going on here to a user and what the implications of getting pwned are? Or, alternatively, is this made scary enough that a user doesn't start filling out random things.

The concern is that if you can send the right bits of information you can attack the hardware, rewrite firmware, and if you are motivated enough, destroy the hardware.

I'm thinking of this small attack: https://www.cybersecurity-insiders.com/cyber-attack-launched-on-150000-printers-working-worldwide/

But is a web page can trick a user to ssh into some server on a company network, that's a pretty scary prospect.

ewilligers

comment created time in 2 days

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++++### Threat++A web app might initiate connections without the user realizing.++### Mitigation++When initiating a connection, the user agent would show some UI.++The user can be asked to specify a hostname or IP address, with an option to permit future connections to this host.++++### Threat++Attackers may use the API to DDOS third parties.++### Mitigation++Connection attempts would be rate limited.

This still allows for passive scans. Maybe this would be in control of the connection UI... the user could then hit a "retry" button, rather than the web page doing it.

ewilligers

comment created time in 2 days

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++++### Threat++A web app might initiate connections without the user realizing.++### Mitigation++When initiating a connection, the user agent would show some UI.++The user can be asked to specify a hostname or IP address, with an option to permit future connections to this host.++++### Threat++Attackers may use the API to DDOS third parties.++### Mitigation++Connection attempts would be rate limited.++Connections will only be able to be initiated after transient activation (user interaction with the page).

This is good, but these can be fairly weak, as scroll events counts as transient activation I believe.

ewilligers

comment created time in 2 days

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++

There is still a threat where a third-party is injected via a first-party context, like via any <script> tag that loads a script from a CDN for instance. Then the third-party script could silently gain access to a socket once the user grants permission.

ewilligers

comment created time in 2 days

issue commentw3c/geolocation-api

Explicitly limit permission lifetimes

The important point is that such algorithms do exist and can impose real risks to the users in the near future.

You raise a good point and I think we are all concerned about that kind of physical tracking. However, I think we will need to deal with things like Naveio more specifically when we get around to doing geofencing.

pes10k

comment created time in 2 days

delete branch w3c/respec-hljs

delete branch : dependabot/npm_and_yarn/elliptic-6.5.3

delete time in 3 days

push eventw3c/respec-hljs

dependabot[bot]

commit sha 7aeed00940d9ace95d802ff3d07ce43855e1ce7c

chore(deps): bump elliptic from 6.5.2 to 6.5.3 (#21) Bumps [elliptic](https://github.com/indutny/elliptic) from 6.5.2 to 6.5.3. - [Release notes](https://github.com/indutny/elliptic/releases) - [Commits](https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

push time in 3 days

PR merged w3c/respec-hljs

chore(deps): bump elliptic from 6.5.2 to 6.5.3 dependencies

Bumps elliptic from 6.5.2 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li>See full diff in <a href="https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 3 days

issue commentw3c/dap-charter

DASWG: Drop Battery API for privacy and lack of implementer support

Oh, that's great to see @reillyeon. Thank you! Looks like Blink folks are coming to the same conclusions. If the mitigations get shipped, I'm still betting on usage going down to 0.00n% usage (and this becoming non-harmful). At the same time, I'm hopeful we can see some legit breakage, so to allow us to deal with those legitimate cases better (e.g., if YouTube is actually using it for some codec selection, then that's probably better done in the <video> element or whatever).

At the same time, it seems Dev Tools is in a way better position to provide accurate battery consumption information on a per tab basis (see "about:performance" in Firefox), which provides a real time view of energy impact of a tab.

Screen Shot 2020-08-03 at 1 47 05 pm

tantek

comment created time in 3 days

issue commentw3c/manifest

Privacy Review: handle start_url tracking

Using a well known URL creates a large migration problem: all currently installed PWAs that don't already conform to the well-known URL would be broken, and for many sites, fixing that problem would require a site re-architecture that might not be that likely to happen. How would that problem be practically addressed?

We'd have to start warning and ask developers to migrate over the next N years. Or a browser vendor would need to take the compat hit. Alternatively, we see what percentage would be impacted and make some determination based on that.

Additionally, removing fragments, queries, and arbitrary paths removes a significant amount of positive utility (the classic tradeoff of the design of URLs). How could you replicate that utility?

Those we would need to look at on a case-by-case basis and see if we can provide the same utility in some other way.

mounirlamouri

comment created time in 3 days

issue commentw3c/respec

Colons in the specification metadata block

Great point.

xfq

comment created time in 3 days

IssuesEvent

issue commentw3c/manifest

Privacy Review: handle start_url tracking

A proposal made internally was just to use a well-known URL. That would basically solve most things: it strips fragments, queries, and arbitrary paths where identifying information could be stored.

That could then be coupled with a hybrid solution: when a user installs an app, partition it into its own storage compartment. Then, for sites that depend on authentication, require the user to log in again using password autofill, webauthn, WebOTP, Credential Management API, or whatever standard authentication mechanism the site depends on. It's a small inconvenience for a big privacy assurance.

mounirlamouri

comment created time in 3 days

issue commentw3c/page-visibility

Unexpected HTML things to check

I agree with @domenic. Incorrect layering to HTML will more than likely lead to implementation issues. Having said that, republishing a CR seems appropriate as we address these issues - but we should make a small push to address them before we start talking about any L3 stuff.

marcoscaceres

comment created time in 6 days

issue commentw3c/web-share

Permissions Policy at risk

Really appreciate the update and looking forward to hearing the outcome of the investigation (that sounds way cooler than it should).

ewilligers

comment created time in 6 days

issue commentw3c/dap-charter

DASWG: Drop Battery API for privacy and lack of implementer support

It relates directly to the discussion we are having here: It's hard to make a case that the spec should be killed when even well meaning implementers, like Brave, are unwilling to follow the spec with regard to SecureContext and Permissions Policy even when returning bogus values.

See what I mean?

tantek

comment created time in 6 days

issue commentw3c/web-share

Permissions Policy at risk

I'm currently sitting on this on the Gecko side (have a patch ready... just stuck in review), but I intend to ship it soon. I'd still encourage us to have this in the spec. Hopeful for support from WebKit. Cc @hober.

ewilligers

comment created time in 6 days

push eventw3c/respec

Fuqiao Xue

commit sha 33532d9f29b5188614ca16d75098eaa9df86875a

chore: add Chinese translation (#3042)

view details

push time in 6 days

delete branch w3c/respec

delete branch : xfq/l10n-zh

delete time in 6 days

PR merged w3c/respec

chore: add Chinese translation
+87 -5

0 comment

21 changed files

xfq

pr closed time in 6 days

issue commentw3c/dap-charter

DASWG: Drop Battery API for privacy and lack of implementer support

But no, Brave has no intention to do any work at all implementing anything relating to the battery API. We don't support it.

Really, then what's this?

Screen Shot 2020-07-31 at 12 08 32 pm

Please understand why I'm getting really pissed off here: Brave is part of the Chromium project and you ship the API (I guess you didn't know that, surprise! 🎉 ), but you seem unwilling to go an actually fix stuff in the Chromium project you depend on.

Anyway, seems like the only solution here is remove SecureContext and Permissions Policy integration from the spec until someone has the actual guts step up and actually implement/ship secure contexts and Permission Policy.

tantek

comment created time in 6 days

issue commentw3c/dap-charter

DASWG: Drop Battery API for privacy and lack of implementer support

In other words, "there aren't enough implementors for the WG to take it on" is a silly complaint,

It's not. It's completely valid. A single implementer spec is not a standard.

but "based on previous experience, we don't think this should be part of the web platform" seems like a totally valid (procedurally and on the substance) reason to remove items from the group's charter / scope of work.

I disagree. And this one provable. @pes10k, stop avoiding my direct question: is Brave going to do the work to actually enable SecureContext and Permission Policy for Battery or not? It's a yes or no question. Intel and Google are not going to do it, so will you or Brave step up and actually do the work?

Additionally, if Intel and Google are not going to do the actual work. They we should remove SecureContext and Permission Policy from the spec. Having fictitious privacy claims in the spec discredits the work on this working group and w3c.

tantek

comment created time in 6 days

create barnchw3c/payment-request

branch : cedex

created branch time in 7 days

push eventw3c/payment-request

Marcos Cáceres

commit sha 28dd285616c2a9273d906853bc2b8b056eeaff4b

chore: ReSpec usage fixes

view details

push time in 7 days

issue commentw3c/screen-wake-lock

Need maximum screen brightness mode

I agree this is something to consider before implementing a full brightness mode. My understanding of the use case is that app developers don't expect users to know how to adjust brightness when they are displaying something like a barcode. To support this case it seems sufficient for the site to provide a hint that full brightness is suggested and the browser can provide the UI to enable it if the user desires.

Agree. It's actually more than "developers don't expect users to know how to adjust brightness".

I've myself been in this situation: you are in line, like getting on a plane (lol, remember those!), or going to a concert (oh god, I'm so sad I miss my old life!), and you open up the app with the ticket.

When you show the ticket, there is social pressure to not hold up the line... so you want the app to put the screen to maximum brightness for maximum contrast, so then you don't need to hand your phone over to the person checking the tickets - and that's how you avoid getting or giving Covid! :)

tomayac

comment created time in 7 days

issue closedw3c/manifest

Privacy Review: handle start_url tracking

To summarize @npdoty comments in https://lists.w3.org/Archives/Public/public-privacy/2015JanMar/0117.html there are concerns about start_url containing special ids or simply something that hints that the user is coming from a homescreen application. This is fingerprinting/privacy sensitive information that the user might not be aware of.

I think the issue of people doing start_url: 'index.html?from_homescreen' is something we might want to mention in the spec but I don't think we should encourage browsers to prevent this because it is clearly something websites want for various reasons (mostly statistics).

However, I am concerned about having start_url: 'index.html?$GUUID' because it is a way to track the user without them being aware of it. I'm not sure what the spec should say or the browsers could do. Maybe we could recommend showing the start_url to the user and allow them to edit it?

closed time in 7 days

mounirlamouri

issue commentw3c/manifest

Privacy Review: handle start_url tracking

Agree. I'm closing this as we acknowledge this problem, but it's not solvable because it's inherent to URLs. We let implementers know this is a problem and provide possibilities to mitigate through the UI. https://www.w3.org/TR/appmanifest/#privacy-consideration-start_url-tracking

mounirlamouri

comment created time in 7 days

issue commentw3c/html-extensions

Should we archive this repo?

@siusin would you mind setting me up with Admin on this repo? I can take care of it if you'd like.

hober

comment created time in 8 days

issue commentw3c/screen-wake-lock

Need maximum screen brightness mode

I think the difference between "default" and "auto" as proposed is significant, as dimming the screen reduces the visibility of the content being displayed and the intent of the API is to allow the content to remain visible.

Agree. I guess the question I have is if it's feasible to implement "default" (no dim) across all OSs? My assumption is that the browser can only request from the OS to keep the screen on (but OS manages what happens), or keep screen on with "full" temporarily (but the OS still manages everything). Is that understanding correct based on what @kenchris documented above? https://github.com/w3c/screen-wake-lock/issues/129#issuecomment-479882316

tomayac

comment created time in 8 days

issue commentw3c/webappsec-permissions-policy

Provide guidance on what to throw?

We could provide some guidance, probably for both exception-based and promise-based APIs.

That would be great. Personally, NotAllowedError in both cases would be fine:

[=throw=] a {{"NotAllowedError"}}` {{DOMException}}.

And:

Return [=a promise rejected with=] a {{"NotAllowedError"}} {{DOMException}}.

marcoscaceres

comment created time in 8 days

Pull request review commentw3c/manifest

Adding field `display_override` to the manifest

 <h2>         with the <a>default display mode</a> (<code>browser</code>) being the         last item in the chain.       </p>+      <p>+        For more advanced usages, the <a data-link-for="WebAppManifest">+        display_override</a> member can be used to specify a custom fallback+        order. This member is valid IFF <a data-link-for="WebAppManifest">display</a> is also present.+      </p>+      <p>+        The algorithm for determing the web app's requested display mode is:+        <ol>+          <li>[=list/For each=] <var>considering_display_mode</var> of <var>+            <a data-link-for="WebAppManifest">display_override</a></var>:+            <ol>+              <li>+                If the user agent supports the |considering_display_mode|,+                then that display mode is used (exit).+              </li>+            </ol>+          </li>+          <li>+            Let |considering_display_mode| be the the value specified by the+            <a data-link-for="WebAppManifest">display</a> property.+          </li>+          <li>+            If the user agent supports the |considering_display_mode|, then+            that display mode is used (exit).+          </li>+          <li>+            While |considering_display_mode| has <a>fallback display mode</a>,+            assign that to |considering_display_mode| and go back to step 3.+          </li>+        </ol>+        This algorithm will end with the final <a>fallback display mode</a> of+        <code>browser</code>, which the user agent MUST support.+      </p>+      </p>       <div class="example">         <p>-          For example, SuperSecure Browser (a fictitious browser) only supports+          Example: SuperSecure Browser (a fictitious browser) only supports           the <code>minimal-ui</code> and <code>browser</code> display modes,           but a developer declares that she wants <code>fullscreen</code> in-          the manifest. In this case, the user agent will first check if it+          the manifest by using the <a data-link-for="WebAppManifest">display

Nit: Same change globally. Avoid using data-link-for= as we now support the new syntax. Quick overview of ReSpec shorthands (and docs): https://respec.org/docs/#Shorthands-Guide

dmurph

comment created time in 8 days

Pull request review commentw3c/manifest

Adding field `display_override` to the manifest

 <h2>         with the <a>default display mode</a> (<code>browser</code>) being the         last item in the chain.       </p>+      <p>+        For more advanced usages, the <a data-link-for="WebAppManifest">+        display_override</a> member can be used to specify a custom fallback+        order. This member is valid IFF <a data-link-for="WebAppManifest">display</a> is also present.+      </p>+      <p>+        The algorithm for determing the web app's requested display mode is:+        <ol>+          <li>[=list/For each=] <var>considering_display_mode</var> of <var>+            <a data-link-for="WebAppManifest">display_override</a></var>:+            <ol>+              <li>+                If the user agent supports the |considering_display_mode|,+                then that display mode is used (exit).+              </li>+            </ol>+          </li>+          <li>+            Let |considering_display_mode| be the the value specified by the+            <a data-link-for="WebAppManifest">display</a> property.+          </li>+          <li>+            If the user agent supports the |considering_display_mode|, then+            that display mode is used (exit).+          </li>+          <li>+            While |considering_display_mode| has <a>fallback display mode</a>,+            assign that to |considering_display_mode| and go back to step 3.+          </li>+        </ol>+        This algorithm will end with the final <a>fallback display mode</a> of+        <code>browser</code>, which the user agent MUST support.+      </p>+      </p>       <div class="example">         <p>-          For example, SuperSecure Browser (a fictitious browser) only supports+          Example: SuperSecure Browser (a fictitious browser) only supports           the <code>minimal-ui</code> and <code>browser</code> display modes,           but a developer declares that she wants <code>fullscreen</code> in-          the manifest. In this case, the user agent will first check if it+          the manifest by using the <a data-link-for="WebAppManifest">display+          </a> property. In this case, the user agent will first check if it
           property. In this case, the user agent will first check if it
dmurph

comment created time in 8 days

Pull request review commentw3c/manifest

Adding field `display_override` to the manifest

 <h2>         with the <a>default display mode</a> (<code>browser</code>) being the         last item in the chain.       </p>+      <p>+        For more advanced usages, the <a data-link-for="WebAppManifest">+        display_override</a> member can be used to specify a custom fallback+        order. This member is valid IFF <a data-link-for="WebAppManifest">display</a> is also present.+      </p>+      <p>+        The algorithm for determing the web app's requested display mode is:+        <ol>+          <li>[=list/For each=] <var>considering_display_mode</var> of <var>+            <a data-link-for="WebAppManifest">display_override</a></var>:+            <ol>+              <li>+                If the user agent supports the |considering_display_mode|,+                then that display mode is used (exit).+              </li>+            </ol>+          </li>+          <li>+            Let |considering_display_mode| be the the value specified by the+            <a data-link-for="WebAppManifest">display</a> property.+          </li>+          <li>+            If the user agent supports the |considering_display_mode|, then+            that display mode is used (exit).+          </li>+          <li>+            While |considering_display_mode| has <a>fallback display mode</a>,+            assign that to |considering_display_mode| and go back to step 3.+          </li>+        </ol>+        This algorithm will end with the final <a>fallback display mode</a> of+        <code>browser</code>, which the user agent MUST support.+      </p>+      </p>       <div class="example">         <p>-          For example, SuperSecure Browser (a fictitious browser) only supports+          Example: SuperSecure Browser (a fictitious browser) only supports           the <code>minimal-ui</code> and <code>browser</code> display modes,           but a developer declares that she wants <code>fullscreen</code> in-          the manifest. In this case, the user agent will first check if it+          the manifest by using the <a data-link-for="WebAppManifest">display
          the manifest by using the {{WebAppManifest/display}}
dmurph

comment created time in 8 days

issue commentw3c/screen-wake-lock

Need maximum screen brightness mode

It sounds like what you are seeing is based on Chrome's implementation, which happens to be holding the lock at a particularly brightness without allowing it do dim - so I'm hoping to hear from the Chrome folks, as I'm not sure who implemented the feature.

Personally, if I was to do this in Firefox, I would only do "full" and "auto" (or default). However, I'm certainly open to this third state:

To reiterate what we have so far:

  • default: use the current brightness, and (if possible) don't allow the screen to dim - (OSs power settings probably override this).
  • auto: use the current brightness, but let the OS do whatever it wants with regards to dimming.
  • full: request full brightness, and let the OS do whatever it wants.

When I say "use the current brightness", the user is still obviously in control and can adjust it. Similarly, in all cases, the OS can do whatever it wants/needs to do based on available battery: the browser shouldn't override the OS, IMO.

As I said, I'm remain skeptical that "default" and "auto" are different (it sounds like an implementation detail of Chrome) - but I'm open to listen to reason as I've not implemented this Firefox yet.

tomayac

comment created time in 8 days

issue commentw3c/html-extensions

Should we archive this repo?

Before we archive it, we need to gut the index.html. We should probably turn off gh-pages for this also.

hober

comment created time in 8 days

issue commentw3c/html-extensions

Should we archive this repo?

Yes, looks like we should. This is in conflict with HTML itself.

hober

comment created time in 8 days

push eventw3c/geolocation-api

Marcos Cáceres

commit sha ea68651aea513cc037324ed5feae5d706b1629a0

Update index.html

view details

push time in 8 days

issue closedw3c/manifest-app-info

Call for Consensus to publish a Working Group Note

Please leave your comments, etc. below.

closed time in 9 days

aarongustafson

issue commentw3c/manifest-app-info

Call for Consensus to publish a Working Group Note

CFC has passed. The chairs and team will work on publishing getting this published on TR.

aarongustafson

comment created time in 9 days

issue commentw3c/webappswg

Publish manifest-app-info as FPWD

Ok cool, CFC is passed. @siusin let me know if you need anything spec wise.

marcoscaceres

comment created time in 9 days

issue commentw3c/geolocation-api

Change text for description of GeolocationPositionError.message attribute

@himorin, @xfq let me know if https://github.com/w3c/geolocation-api/pull/51/ is a suitable fix.

himorin

comment created time in 9 days

push eventw3c/geolocation-api

Marcos Cáceres

commit sha 904c9e95c5c84b1fa6b6012b5b3e667f3a685dbb

Editorial: s/feature policy/permissions policy (#52)

view details

Marcos Cáceres

commit sha 61929d3bf217d5cf3026ae17485fc66547411017

Editorial: Add sections, markup fixes, nits (#46)

view details

Marcos Cáceres

commit sha e281da86e4bc2a93162516b77a67bf683181f489

Merge branch 'gh-pages' into i18n_message

view details

push time in 9 days

more