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

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

Received on Wednesday, 23 January 2019 11:05:16 UTC