solid/specification

Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct

Sarven Capadisli

@csarven

Personally, I would only block (403) IP addresses that I know or well-known to be acting outside of the terms of my service.

Fred Gibson

@gibsonf1

This is in the sense of a request coming into the server using an ip address instead of a DNS request (not the origin), like 5.161.48.158/profile/card instead of https://frederick.trinpod.us/profile/card

Feb 15 20:04:36 make trinity[842703]: 103.203.57.25 - [15/Feb/2022:20:04:36 +00:00] "GET 5.161.48.158:/ HTTP/1.1" 200 2528 "-" "HTTP Banner Detection (https://security.ipip.net)"

I guess something like this scanning / with ip could be ok, but this is for sure a hacker:

Feb 15 20:03:17 make trinity[842703]: 45.146.165.37 - [15/Feb/2022:20:03:17 +00:00] "POST 5.161.48.158:/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 404 683 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"

So maybe the rule would be any non / request by an ip address should get 40?

Fred Gibson

@gibsonf1

But good point, 404 unless it for sure is violating TOS

Jeff Zucker

@jeff-zucker

Also for a hacker 404 is "try the next thing" and 403 is "what can I do to get that"

Fred Gibson

@gibsonf1

Ahh yes, people want what they cant get. I was also trying, for true hackers, to send no reply or something like that

But then I would have to reserve a thread for hackers where the request is sent to die and timeout the other side

Sarven Capadisli

@csarven

A request can be forbidden (403) for any reason.

Kjetil Kjernsmo

@kjetilk

Feb 15 20:03:17 make trinity[842703]: 45.146.165.37 - [15/Feb/2022:20:03:17 +00:00] "POST 5.161.48.158:/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 404 683 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"

Those are cute... I see lots and lots of them impinging on my servers too. That's why I think it is important to have a processing step ahead of anything heavy that can reject stuff like that

Fred Gibson

@gibsonf1

:thumbsup:

I added this function at the top of all routes:

(defmethod reject-ip-request ()
  (when *request*
    (let ((server (request-server-name *request*))
      (path (request-uri *request*)))
      (when (or (not (stringp server))
        (not (stringp path))
        (and (?ip-address server)(not (string= path "/"))))
    (throw-code 404)))))

So if an IP request comes in for anyting other than /, 404

Sarven Capadisli

@csarven

@kjetilk , welcome to the W3C Solid CG! Here are some issues...

Sarven Capadisli

@csarven

Notifications Panel meeting now: https://gitter.im/solid/notifications-panel?at=621790a2d1b64840db397b0b

Mathlouthi Khaled

@odaper

Hello, I'm joining the SOLID community and I'll contribute to this great idea, but I still have some questions: if my company will have its own POD that will hold all confidential data of its employees, the risk of cyberattack is higher than before right? because today my company have multiple databases by application like HRPortal, Intranet...etc if they will be moved to one place I think that the risk will be higher, what do you think?

sjoertrix

@sjoertrix:utwente.io

[m]

Interesting question. When you have stuff with 10 suppliers, the risk of getting hacked might be 10x. And you don't have much control about security, country or policies.
With Solid it is easier to be in control of your data, you decide where you leave your data. You could choose to leave some HRdata with a different Solid supplier, but you have the option to store your data where you choose.

1 reply

This question might be more appopriate in the general solid chat.

Mathlouthi Khaled

@odaper

Hello, why the RDF/XML should be used to read/write data in the POD instead of JSON-LD? our Stateless apps today are using JSON so I think that moving to RDF via REST API may create a breaking change in the existing web apps and migrating to SOLID PODS will be complicated. I support the idea of SOLID and I'll contribute to this great project but for now I'm trying to understand and identify the problems that we may face in the future. Many thanks for your answers

Sarven Capadisli

@csarven

@odaper RDF/XML is not required by the Solid Protocol. Where did you come across that information?

9 replies

Sarven Capadisli

@csarven

:bell: Daylight saving time changes up ahead... everyone get abacuses out.

Kjetil Kjernsmo

@kjetilk

OMG!

Sarven Capadisli

@csarven

@/all I propose that we communicate all CG meetings using UTC throughout the year. We let anyone/state observing daylight saving time adjust to it as they need to.

Kjetil Kjernsmo

@kjetilk

:+1: yeah, that makes sense since we're out of sync every now and then

Sarven Capadisli

@csarven

It'd be great to keep current panels at the same time slot. I'd suggest 14:00 UTC... Keeping the following in mind:

Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.

https://github.com/solid/specification/blob/main/meetings/template.md#participation-and-code-of-conduct

Kjetil Kjernsmo

@kjetilk

:+1: I suppose each panel should find their own time slot, but setting the time in UTC to not make it dependent on various daylight savings time and stuff is good

Aaron Coburn

@acoburn

The Authentication Panel has been incubating the Solid-OIDC specification for the last several years. Today was an important milestone in that the panel has voted to promote Solid-OIDC from a purely "editors draft" document to a Community Group Draft: roughly equivalent to a FPWD. A repository tag was created with the version number of this draft. This is all in preparation for a summertime target of ~CR status.

At present, the Solid-OIDC draft specification is available at https://solid.github.io/solid-oidc/ via a GitHub pages workflow. I would like to discuss how we can start moving these drafts into the https://solidproject.org/TR/ namespace, presumably under oidc. Ideally, we will have an automated process via GH, but for now a manual process should suffice.

What would be the best way to proceed here?

Jeff Zucker

@jeff-zucker

Congrats on and thanks for the work!

Justin Bingham

@justinwb

huge milestone - great work

Sarven Capadisli

@csarven

@acoburn If you'd like to publish the CG-DRAFT at https://solidproject.org/TR/solid-oidc and https://solidproject.org/TR/2022/solid-oidc-20220328 (with links referring to each other and possibly including links to the ED) then please make a PR of the final HTML and scripts/media to the solid/specification repository .

On a related note, you may want to note solid/solid-oidc#98

Justin Bingham

@justinwb

@acoburn the current mechanism is automated in that whatever is committed into solid/specification is published to the corresponding github pages for that repo, which is then in turn proxied (via rewrite) from /TR/

(note that alain, jackson, and i have been working on a project to migrate solidproject.org to CSS (nearly done), at which point we’ll move on from the proxy/rewrite to direct deployment)

Sarven Capadisli

@csarven

@acoburn The table in the document at TR/ can also be updated with the new information. Let me know if you'd like to go ahead with that or wait for the publications of the CG-DRAFT under TR/

Aaron Coburn

@acoburn

Thanks for the pointers -- I'll start with a PR to the specification repo. If it's easy to also update the TR/ table at the same time, I will do that; otherwise, I'll do this in two steps

Kjetil Kjernsmo

@kjetilk

Great work, @acoburn !

I'm looking forward to review it

Jeff Zucker

@jeff-zucker

In https://solidproject.org/TR/protocol#storage, when it says "Servers exposing the storage resource MUST advertise by including the HTTP Link header [...show a pim:Storage link]" ... what is the meaning of "servers exposing"? Does that mean any server with a storage or a server that chooses to advertise its storages? If it is optional to expose a storage, is it therefore only a MUST to show the header if the option is taken and therefore no absolute requirement to send a pim:Storage link header?

Sarven Capadisli

@csarven

@jeff-zucker I think we can make that more clear.

The understanding/agreement was that 2xx responses MUST include the Link header with pim:Storage. Normally - or is it just in my head? - 4xx - more interestingly 401/403 - shouldn't include information in the headers that reveal the semantics of the target resource. However, there are/may be exceptions in that in order to enable a feature (for clients) with minimal information, e.g., discovery of root contain/storage, through URL path hierarchy, we'd need the Link header with pim:Storage irrespective of the status code.

The way I interpret the current text - that I wrote - is that the header is always included.

I'd like to hear from server/application implementers. Is your server exposing the header at all times or limited to certain requests/responses? For Storage locations besides the root URL path (/ after authority:port) I can't see how clients can work out a URI is allocated to identify the storage.

Jeff Zucker

@jeff-zucker

@csarven My understanding is that pim:Storage only tells us that the container is a storage, not who owns the storage, which requires an optional solid:owner predicate in the metadata of the container or in the profile. Since you previously told me that a WebID profile can exist in a storage owned by someone other than the WebID owner, one can not assume that a storage belongs to any given agent unless the solid:owner predicate is found somewhere. So one can count on knowing that something is a Storage but one can not count on knowing who owns it, correct?

Jeff Zucker

@jeff-zucker

OTOH, if an app is acting on behalf of the WebID owner and knows something is a pim:Storage it could try to write there and if it gets a 2xx, it can store information there on behalf of the WebID owner even if not certain they are the owner of the storage.

Jeff Zucker

@jeff-zucker

And, I suppose if the app acting on behalf of the WebID owner can also Control what it writes, it can assume that the WebID owner is at least "co-owner" of the storage.

Sarven Capadisli

@csarven

I think "on behalf of" is covered by acl:delegates.

Sarven Capadisli

@csarven

There is no way to derive/infer the owner of something without following some links/relations based on the specs.

elf Pavlik

@elf-pavlik

https://solid.github.io/data-interoperability-panel/specification/#data-grant provides out of band information about the data owner of all resources under that grant

SAI also has pretty advanced work on basic delegation (end-user to app), in Solid-OIDC end-user is denoted by webid and the app by client_id
We also have tracking issue to support longer delegation chains which can be very powerful: solid/data-interoperability-panel#222

elf Pavlik

@elf-pavlik

https://www.npmjs.com/package/@janeirodigital/interop-application#example shows how an application can nicely traverse all the data it can access for given data owner

gitter is not the best example but slack for example strongly groups chats by an organization, various project management apps also group projects by organizations. Data Grants allow apps to provide similar UX very easily, and lazily fetch data only when it's going to be displayed to the user (important on mobile devices).

Jeff Zucker

@jeff-zucker

What is the current status of TLS in relation to Solid? Is it implemented anywhere? Is it in any current spec? Should certs for it be in the WebID Profile?

Where communities thrive

People

Repo info

Activity