W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > January 2019

RE: [dxwg] Profiles Guide doc Security and Privacy (#478)

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Fri, 25 Jan 2019 08:35:17 +0000
To: Annette Greiner <amgreiner@lbl.gov>
CC: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <6293feb9647343e7a8a4136fba5c4f2b@dnb.de>
Hi Annette,

On Wednesday, January 23, 2019 8:02 PM, Annette Greiner [mailto:amgreiner@lbl.gov] wrote:

> Question 4.13 asks about distinguishing behavior in 1st party and third
> party contexts. I was thinking about third parties like advertisers and
> their third-party cookies. It would be good to prevent profile request
> information from reaching those sorts of third parties, but I'm not sure
> how practical it would be. Can we say something like "Profile settings
> information MUST not be passed to a third party"? Anyway, the answer you
> have to the question is accurate, I'm just thinking we might want to add
> something to the spec to address the issue.

OK, I see your point and no, I don't think that we can prevent the passing on of profile setting information to third parties (although I'd love to be proven wrong!). Can you suggest some text?

> Re the more general comment about offering some MUSTs, see above for an
> example. But this observation is about the spec, not the replies to the
> security questions. In the next round, we might want to add some
> language like "Profile setting data MUST NOT be stored by origins."

Right, but that would be for privacy reasons, not for technical reasons. Right?

Best,

Lars

> On 1/23/19 3:04 AM, Svensson, Lars wrote:
> > Hi Annette,
> >
> > On Tuesday, January 08, 2019 1:09 AM, Annette Greiner
> [mailto:amgreiner@lbl.gov] wrote:
> >
> >> Thanks for following up on this.
> > Thanks for your feedback! I've updated the wiki page [1] to the best of my
> understanding while taking the liberty to use some of your suggestions verbatim.
> >
> >
> >> I think we should address question 4.1 a bit more fully. Since the web
> >> server receives information about all profiles prioritized, it could
> >> obtain information about the user that identifies them by the overlap of
> >> profiles or a profile plus their IP address. For example, if a user
> >> requests information with a profile used in a specific area of interest
> >> and also a company-specific profile, the identity of the person could
> >> become knowable (e.g., a person interested in model railroads who works
> >> for Adobe in San Francisco). Moreover, any health-specific profile
> >> information could hint at personal health information. Also, it's worth
> >> considering that marketers could look for specific profiles for targeted
> >> advertising.
> > OK.
> >
> >> The question about high-value data (4.2) is interesting. There's no
> >> reason conneg could not be used for high-value data. Could the specific
> >> profile chosen to obtain high-value data have consequences? What happens
> >> if stock traders share a profile and that footprint were suddenly seen
> >> more frequently at a certain company's web site? Could that information
> >> get passed to a third party? Perhaps this specification should actually
> >> distinguish between first-party and third-party contexts.
> > I don't think I quite understand what you mean here, particularly your distinction
> between first-party and third-parte contexts... Can you suggest some text?
> >
> >> Question 4.5 should be a yes, I think. Profile preference information is
> >> exposed to the origin server.
> > OK.
> >
> >> Re persisting data to the user's local device, the profile settings in a
> >> browser that supports content negotiation by profile would be persisted.
> > That's 4.15. OK.
> >
> >> Re enabling persistent monitoring, a user with specific settings for
> >> profiles could be tracked by the headers created by those settings. The
> >> feasibility of that technique of monitoring depends on the uniqueness
> >> and the prevalence of profile settings.
> > That's 4.16. OK.
> >
> >> I think the above all depends on whether and how browser makers support
> >> content negotiation by profile. It might be worth considering adding
> >> some MUSTs to ensure security in future browsers.
> > Here too: Can you suggest some text?
> >
> >> 4.14 has a typo, I think. It says "The only difference could be that the
> >> use or profile URIs is prohibited in private browsing mode". That
> >> probably should say "use of profile URIs".
> > Fixed.
> >
> >> 4.15 has a typo, I think. It says "This specification defines a
> >> request-/response-interaction and does not specify and storage of data."
> >> That probably should say "does not specify any storage".
> > Fixed.
> >
> > Thanks again!
> >
> > [1] https://www.w3.org/2017/dxwg/wiki/CnegPrivacyAndSecurityQuestionnaire

> >
> > Best,
> >
> > Lars
> >
> >> On 1/7/19 7:23 AM, Svensson, Lars wrote:
> >>> Dear Annette,
> >>>
> >>> On Monday, December 17, 2018 6:59 PM, Annette Greiner
> >> [mailto:amgreiner@lbl.gov] wrote:
> >>>> oops, sorry, my comments were for the prof conneg doc, not the guidance!
> >>> So are your comments relevant for the prof-conneg security and privacy
> section
> >> [1]? To me they don't directly address anything in that section or in the answers
> to
> >> the questionnaire [2].
> >>> [1] https://www.w3.org/TR/dx-prof-conneg/#security_and_privacy

> >>> [2]
> https://www.w3.org/2017/dxwg/wiki/CnegPrivacyAndSecurityQuestionnaire

> >>>
> >>> Best,
> >>>
> >>> Lars
> >>>
> >>>> On 12/15/18 12:08 PM, Nicholas Car via GitHub wrote:
> >>>>> Questions from https://w3ctag.github.io/security-questionnaire/ with
> >>>>> answers:
> >>>>> **4.1 What information might this feature expose to Web sites or other
> >>>>> parties, and for what purposes is that exposure necessary?**  Guidance
> >>>>> document - no code/system exposing anything directly.
> >>>>> **4.2 Is this specification exposing the minimum amount of information
> >>>>> necessary to power the feature?**  N/A
> >>>>> **4.3 How does this specification deal with personal information or
> >>>>> personally-identifiable information or information derived thereof?**
> >>>>> It does not.
> >>>>> **4.4 How does this specification deal with sensitive information?**
> >>>>> It does not.
> >>>>> **4.5 Does this specification introduce new state for an origin that
> >>>>> persists across browsing sessions?**  No.
> >>>>> **4.6 What information from the underlying platform, e.g.
> >>>>> configuration data, is exposed by this specification to an origin?**  N/A
> >>>>> **4.7 Does this specification allow an origin access to sensors on a
> >>>>> user’s device?**  No.
> >>>>> **4.8 What data does this specification expose to an origin? Please
> >>>>> also document what data is identical to data exposed by other
> >>>>> features, in the same or different contexts.**  N/A
> >>>>> **4.9 Does this specification enable new script execution/loading
> >>>>> mechanisms?**  No.
> >>>>> **4.10 Does this specification allow an origin to access other
> >>>>> devices?**  No.
> >>>>> **4.11 Does this specification allow an origin some measure of control
> >>>>> over a user agent’s native UI?**  No.
> >>>>> **4.12 What temporary identifiers might this this specification create
> >>>>> or expose to the web?**  No temporary identifiers. Use of it will
> >>>>> ultimately generate persistent identifiers (URIs) for documents
> >>>>> (profiles).
> >>>>> **4.13 How does this specification distinguish between behavior in
> >>>>> first-party and third-party contexts?**  It does not.
> >>>>> **4.14 How does this specification work in the context of a user
> >>>>> agent’s Private \ Browsing or "incognito" mode?**  N/A
> >>>>> **4.15 Does this specification have a "Security Considerations" and
> >>>>> "Privacy Considerations" section?**  Yes but a trivial one for now. To
> >>>>> be updated.
> >>>>> **4.16 Does this specification allow downgrading default security
> >>>>> characteristics?**  No or N/A.
> >>>>> **4.17 What should this questionaire have asked?**  I can't think of
> >>>>> what it could ask to better probe potential privacy issues for this
> >>>>> kind of Guidance document.
> >>>>>
> >>>>>
> >>>> --
> >>>> Annette Greiner
> >>>> NERSC Data and Analytics Services
> >>>> Lawrence Berkeley National Laboratory
> >>>>
> >> --
> >> Annette Greiner
> >> NERSC Data and Analytics Services
> >> Lawrence Berkeley National Laboratory
> 
> --
> Annette Greiner
> NERSC Data and Analytics Services
> Lawrence Berkeley National Laboratory

Received on Friday, 25 January 2019 08:35:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 25 March 2019 10:33:29 UTC