profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ingben/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Ingo Bente ingben Hamburg CISO in Hamburg. Boardgame fanatic. Organizer of HHsecurity meetup and @elbsides security conference.

mswimmer/beta.elbsides.de 1

test code for Elbsides

ingben/awesome-appsec 0

A curated list of resources for learning about application security

ingben/DVWA 0

Damn Vulnerable Web Application (DVWA)

ingben/juice-shop 0

OWASP Juice Shop is an intentionally insecure webapp for security trainings written entirely in Javascript which encompasses the entire OWASP Top Ten and other severe security flaws.

ingben/nebula-exploits 0

Digging through https://exploit-exercises.com/nebula/

ingben/scable 0

scable is a wirespeed point to point encryption software

Pull request review commentw3c/webappsec

[charter 2021] allow going to rec; require 2x intent to implement

 <h3> 	  <h2>Success Criteria</h2> 	  <p>In order to advance to <a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, each normative specification is expected to have <a href="https://www.w3.org/Consortium/Process/#implementation-experience">at least two independent implementations</a> of every feature defined in the specification.</p> 	  <p>Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.</p>+  	  <p>All new features should be supported by at least two intents to implement before being incorporated in the specification.</p>

I agree with the comments from Mike and Anne. The proposed text in the PR matches the spirit of what we intend in shorthand, but might be too blunt and invite rule-lawyering. I like the nuance of the WHATWG working-mode document and would like to capture more of it.

I imagine it's not allowed to have external definitions in a charter, since they technically could change out from under us. And it's kind of a lot of text to incorporate wholesale (and might need tweaks besides). As a short form the sentence Wendy proposed two comments above is better.

samuelweiler

comment created time in a day

push eventpivotal/LicenseFinder

Shane Lattanzio

commit sha 6fdf9d2e2a0efbaa3e4afed2aff23ca00178d599

Cocoapod escape

view details

push time in a day

issue commentw3c/webappsec

Web Applications should not have internet access by default

Serious web applications, such as a local document creator or editor, need to isolate parts of their program from the network, such as with the per-module network isolation proposal mentioned above, both for the security and privacy of users and for being able to integrate local desktop activities into a trusted environment.

This implies a new security model for the internet that needs to be shifted from the remote server to the local machine hosting the browser. The remote server is always "potentially trustworthy" (as per the HTML specification) but not truly secure. What is truly secure for the users is the local machine hosting the browser. Thus the idea that Web Applications should have a local (and not remote) security model pertaining to network access.

One thought that W3C would have had more incentive to innovate than whatwg. Whatwg closed all the related proposals, asking first for browser implementation before even considering it. At the same time, it is very clear that they are lost into countless technical problems related to the actual content-security-policy, which could easily and elegantly be solved by declarative network isolation via a specific attribute within insecure HTML tags.

One doesn't really know what could be the place for it, apart from building an alternative World Wide Web which would be secure by default for users ( and that was in fact, it seems to one, the original intent of the web inventors : to have the ability to securely access local files on a local network, without the security model being defined remotely).

abflow

comment created time in 2 days

Pull request review commentw3c/webappsec

[charter 2021] allow going to rec; require 2x intent to implement

 <h3> 	  <h2>Success Criteria</h2> 	  <p>In order to advance to <a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, each normative specification is expected to have <a href="https://www.w3.org/Consortium/Process/#implementation-experience">at least two independent implementations</a> of every feature defined in the specification.</p> 	  <p>Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.</p>+  	  <p>All new features should be supported by at least two intents to implement before being incorporated in the specification.</p>

Wendy: yes and yes. 😊 (Though that window should be somewhat large, on the order of years.)

samuelweiler

comment created time in 2 days

Pull request review commentw3c/webappsec

[charter 2021] allow going to rec; require 2x intent to implement

 <h3> 	  <h2>Success Criteria</h2> 	  <p>In order to advance to <a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, each normative specification is expected to have <a href="https://www.w3.org/Consortium/Process/#implementation-experience">at least two independent implementations</a> of every feature defined in the specification.</p> 	  <p>Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.</p>+  	  <p>All new features should be supported by at least two intents to implement before being incorporated in the specification.</p>

Would you say instead: "New features should be expected to have at least two implementations, as judged by expressions of interest (and lack of opposition)."?

Another question we've heard is whether features should be dropped after some time window if expected implementations don't materialize. Thoughts?

samuelweiler

comment created time in 2 days

Pull request review commentw3c/webappsec

[charter 2021] allow going to rec; require 2x intent to implement

 <h3> 	  <h2>Success Criteria</h2> 	  <p>In order to advance to <a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, each normative specification is expected to have <a href="https://www.w3.org/Consortium/Process/#implementation-experience">at least two independent implementations</a> of every feature defined in the specification.</p> 	  <p>Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.</p>+  	  <p>All new features should be supported by at least two intents to implement before being incorporated in the specification.</p>

Came here to say what @mikewest already said.

samuelweiler

comment created time in 2 days

issue commentpivotal/LicenseFinder

Improving performance with npm

I'm going to close this out since I no longer work on the project that spawned this issue. I never did find a resolution, though.

NickWer

comment created time in 2 days

issue closedpivotal/LicenseFinder

Improving performance with npm

Hi, is there any way we can improve the runtime for our modestly sized nodejs project? We have ~83 dependencies, and LicenseFinder takes around around 7 minutes to run, but closer to 10 when our CI runners are under load. All suggestions are welcome 🙂

closed time in 2 days

NickWer

push eventw3c/webappsec

Wendy Seltzer

commit sha 7aab8d285356c797a27ae19f0ad0c2a923f85200

Update webappsec-charter-2021.html s/may/will/

view details

push time in 2 days

Pull request review commentw3c/webappsec

[charter 2021] allow going to rec; require 2x intent to implement

 <h2>           Deliverables         </h2> -        <p>More detailed milestones and updated publication schedules are available on the <a href="https://www.w3.org/groups/wg/webappsec/publications">group publication status page</a>.</p>--	<p><i>Draft state</i> indicates the state of the deliverable+	<p><i>Draft state</i>, below, indicates the state of the deliverable 	at the time of the charter approval.</p> +	<p>Current document status is available on the <a href="https://www.w3.org/groups/wg/webappsec/publications">group publication status page</a>.</p>+	       	<p>With the exception of the Mixed Content specification, the 	  Working Group intends to publish the latest state of their-	  work as Candidate Recommendation (with Snapshots) and does-	  not intend to advance their documents to Recommendation.</p>+	  work as Candidate Recommendation (with Snapshots). The group may advance

No objection.

samuelweiler

comment created time in 2 days

Pull request review commentw3c/webappsec

[charter 2021] allow going to rec; require 2x intent to implement

 <h3> 	  <h2>Success Criteria</h2> 	  <p>In order to advance to <a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, each normative specification is expected to have <a href="https://www.w3.org/Consortium/Process/#implementation-experience">at least two independent implementations</a> of every feature defined in the specification.</p> 	  <p>Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.</p>+  	  <p>All new features should be supported by at least two intents to implement before being incorporated in the specification.</p>

So far as I can tell, only Mozilla and Google have a common practice of sending something like "intent to implement/prototype" emails. WHATWG's policy document says "Living Standards are intended to include only those features that are likely to be implemented in major browser engines and are suitable for adoption and implementation by other browser engine developers and integrators.", HTML's PR template includes "At least two implementers are interested (and none opposed):", and their working mode document has some nuanced suggestions.

With that in mind, it might be reasonable to frame this a little less narrowly?

samuelweiler

comment created time in 2 days

issue commentw3c/webappsec

Web Applications should not have internet access by default

There is a set of Web Applications that don't need network access following page load, and I agree that the user would be well-served by having those applications give up network access and by being informed when that has (and hasn't) happened.

Take, for example, a compound interest calculator. You can't write it as a simple HTML document, and there's gain for the user in having it give up network access after loading.

I also know that many sites use JavaScript when they could get away without it, so there are also opportunities where a user would want to deny a site network access.

So while I'm intrigued by the idea, I share dveditz's doubts that this WG is the place for it.

abflow

comment created time in 2 days

Pull request review commentw3c/webappsec

[charter 2021] allow going to rec; require 2x intent to implement

 <h2>           Deliverables         </h2> -        <p>More detailed milestones and updated publication schedules are available on the <a href="https://www.w3.org/groups/wg/webappsec/publications">group publication status page</a>.</p>--	<p><i>Draft state</i> indicates the state of the deliverable+	<p><i>Draft state</i>, below, indicates the state of the deliverable 	at the time of the charter approval.</p> +	<p>Current document status is available on the <a href="https://www.w3.org/groups/wg/webappsec/publications">group publication status page</a>.</p>+	       	<p>With the exception of the Mixed Content specification, the 	  Working Group intends to publish the latest state of their-	  work as Candidate Recommendation (with Snapshots) and does-	  not intend to advance their documents to Recommendation.</p>+	  work as Candidate Recommendation (with Snapshots). The group may advance

Suggest s/may/will/

samuelweiler

comment created time in 2 days

push eventw3c/webappsec

Wendy Seltzer

commit sha aceff23268a0c69b0819cfff8d66f8f47961082b

Update webappsec-charter-2021.html editorial (an extra when->to)

view details

push time in 2 days

delete branch w3c/webappsec

delete branch : permission_scope

delete time in 2 days

push eventw3c/webappsec

Marcos Cáceres

commit sha 83b583b10c38fa85cb5d9ce42b114e0d2ec98c30

Widen scope of Permission API

view details

Samuel Weiler

commit sha edef510d9d0d86ffabde1a9b099bde903aae5e25

Merge pull request #579 from w3c/permission_scope Widen scope of Permission API

view details

push time in 2 days

PR merged w3c/webappsec

Widen scope of Permission API

We are looking at expanding the scope of Permissions API to have opinions about UI, lifetimes, etc. so the text is overly restrictive.

+1 -5

5 comments

1 changed file

marcoscaceres

pr closed time in 2 days

pull request commentw3c/webappsec

Widen scope of Permission API

I support removing the limit on the scope; we can keep discussing what to actually do in the doc.

marcoscaceres

comment created time in 2 days

PR opened w3c/webappsec

allow going to rec; require 2x intent to implement

per discussions on 20 April 2021 WG call: https://github.com/w3c/webappsec/blob/main/meetings/2021/2021-04-20-minutes.md

+7 -5

0 comment

1 changed file

pr created time in 2 days

create barnchw3c/webappsec

branch : charter-2021-rec-intent

created branch time in 2 days

issue commentpivotal/LicenseFinder

Add ability to truncate additional output

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

heydonovan

comment created time in 2 days

issue openedpivotal/LicenseFinder

Add ability to truncate additional output

Hi Team --

We are trying to reduce the output size when running the license scanning tool over on GitLab. Currently the license scanning tool is producing more than 8MB of logs. We tried passing in various environment variables to further reduce the output, but the flags are either not working or just aren't reducing it enough. Here is the current command:

license_management report --prepare-no-fail --format=json --save=gl-license-scanning-report.json --no-recursive --no-debug --quiet

Are there additional flags we might be able to pass to further reduce the output? The jobs over on GitLab are truncated which is why we are trying to do this, so we can see the errors at the end (when/if things go wrong).

created time in 2 days

issue commentw3c/webappsec

Concerns with moving to living standard model

Thanks for the comment @pes10k. Speaking as a team contact for the group, but not speaking for the group, I'll try to reflect some of the discussions I've heard. According to the Process, a group operating in a living standard mode should publish Candidate Recommendation Snapshots periodically (6-24 months, depending on pace of changes), with update requests. (Adding to @marcoscaceres reference, these update requests may be at the Candidate Recommendation or Revised Recommendation status.)

  1. The WG retains change control over the spec, and should set criteria that things get deliberation and consensus before they go into the WD or Snapshot. Those criteria can be spelled out in the charter.
  2. Horizontal and wide review are required before each update request, just as they are now before Candidate Recommendation. Objections must be addressed before publication. If a reviewer says they need to see more of a package of changes before supporting an update, that could be a meaningful review comment.

I think the group's thinking was that security specs want to be pointing developers and implementers to the latest recommended practices, and so the charter should make it easy to keep those specs current.

Any thoughts on safeguards you'd like to see in the charter to ensure living standards work gets appropriate review and consensus?

pes10k

comment created time in 5 days

PR opened PagerDuty/incident-response-docs

A few grammar updates

While reviewing the documentation, I stumbled over a few phrases. I have updated them as I saw appropriate. Each change is broken into separate commits if you chose to keep some but not the others.

+6 -6

0 comment

5 changed files

pr created time in 5 days

release juice-shop/juice-shop-ctf

v8.2.1

released time in 5 days

created repositoryjuice-shop/juicy-statistics

Scripts to collect statistics about OWASP Juice Shop

created time in 9 days

pull request commentpivotal/LicenseFinder

Upgrade to GitHub-native Dependabot

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

dependabot-preview[bot]

comment created time in 10 days

create barnchpivotal/LicenseFinder

branch : dependabot/add-v2-config-file

created branch time in 10 days

PR opened pivotal/LicenseFinder

Upgrade to GitHub-native Dependabot

Dependabot Preview will be shut down on August 3rd, 2021. In order to keep getting Dependabot updates, please merge this PR and migrate to GitHub-native Dependabot before then.

Dependabot has been fully integrated into GitHub, so you no longer have to install and manage a separate app. This pull request migrates your configuration from Dependabot.com to a config file, using the new syntax. When merged, we'll swap out dependabot-preview (me) for a new dependabot app, and you'll be all set!

With this change, you'll now use the Dependabot page in GitHub, rather than the Dependabot dashboard, to monitor your version updates, and you'll configure Dependabot through the new config file rather than a UI.

If you've got any questions or feedback for us, please let us know by creating an issue in the dependabot/dependabot-core repository.

Learn more about migrating to GitHub-native Dependabot

Please note that regular @dependabot commands do not work on this pull request.

+9 -0

0 comment

1 changed file

pr created time in 10 days