Meeting Notes
Notes from today's Links Research Group meeting:
Places to store data:
- URL
- Hidden fields
- Cookie
- Database
- JavaScript state
- Server state
Parameters/issues around these storage types:
- For data the client will handle, we need security options
- Data stored in the database can be under an imported schema or the schema can be auto-generated from the a type in the language.
- Cookies have names
- Tables have names
- Server-side data might have security options, too
The idea was raised by Jeremy of offering different "views" to the same data, particularly data in the database. Ezra noted that this is true to common practice, where oftentimes an Obejct-Relational mapping is used to provide a layer of data abstraction above the database. Phil noted his work on alternate "views" of data structures in a functional language, supported by conversion functions that convert between representations.
Reasons for encryption:
- protect data from intruders
- protect data from everyone, as with passwords (think one-way encryption)
- keep client data secret from the server (begging proof-carrying code as a way for the user to trust the client-side code)
- keep algorithms & other server-side proprietary data secret
Rodney mentioned that database systems already have the notion of separate read/write authorization for fields; could a similar policy could be used to prevent different pieces code from modifying given pieces of data, even if some code is on the client and some on the server?