Engineer goes off and creates the initial plan & sends it around. At a high level,it looks like this:
Client side code
Set up
snippet lets users know there is a new options in preferences
if the app language pref does not map to a supported language, the pref panel is greyed out with a message that their language is not supported by the EU service
if it does, user clicks ToS, privacy policy checkbox, confirms language
app contacts server
if server not available, throw up offline error
if server available, upload device id, language, url list
notify user setup is complete
enable upload service
When new tab is opened or refreshed
using device id, send a sql query for matching row of url+device id
Server side code
Set up
poked by client, adds rows to table, one for each url (tab)
Periodic background translation job:
finds urls of rows where the translated blob is missing
for each url, submits untranslated blob to EU’s service
sticks the resulting translated text blob back into the table
Periodic background deletion job:
finds rows older than 2 days and evicts them
unless that is the last row for a given device id, in which case hold for 90 days
Database layout
table columns: device id, url, timestamp, language, untranslated text, translated text
The 3rd Meeting:
Engineer: Did y’all have a chance to look over the plan I sent out? I haven’t received any email feedback yet.
DBA: I have a lot of concerns about the database table design. The double text blobs are going to take up a lot of space and make the server very slow for everyone.
Operations Engineer: ..and the device id really should not be in the main table. It should be in a separate database.
Engineer: why? That’s needless complexity!
Operations Engineer: Because it should be stored in a more secure part of the data center. Different parts of the data center have different physical & software security characteristics.
Engineer: “ oh”
Engineering Manager: You should design your interactions with the server to encapsulate where the data comes from inside the server. Just query the server for what you want and let it handle finding it. Building the assumption that it all comes from one table into your code is bad practice.
Engineer: ok
DBA: The double blobs of text is still a problem.
Engineer: Ok, well, let’s get rid of the untranslated text blob. I’ll take the url and load the page and acquire the text right before submitting it to the EU service. How does that sound?
Engineering Manager: I like that better. Also allows you to get newest content. Web pages do update.
Privacy Rep: I was wondering what your plans are for encryption? I didn’t see anything in your draft after it either way.
Engineer: If it’s on our server and we’re going to transmit it to an outside service anyway, why would we need encryption?
Privacy Officer: We’ll still have a slew of device ids stored. At the very least we’ll need to encrypt those. Risk mitigation.
Engineer: But they’re our servers!
Operations Engineer: Until someone else breaks in. We’ve agreed that the device ids will go in a separate secure table, so it makes sense to encrypt them.
Engineer: fine.
Privacy Officer: The good news is that if you design the url/text table well, I don’t think we’ll need to encrypt that.
Engineer: That’s your idea of good news?
Engineering Manager: Privacy Officer is here to help. We’re all here to help.
Engineer: Right, Sorry Privacy Officer.
Privacy Rep: It’s ok. Doing things right is often harder.
Privacy Officer: Anyway, I wanted to let you all know that I’ve started talking with Legal about the terms of service and privacy policy. They promise to get to it in detail next month. So, as long as we stay on the stage servers, it won’t block us.
Engineering Manager: thanks. Do you have any idea how long it might take them once they start?
Privacy Officer: Usually a couple weeks. Legal is very, very through. I think it’s a job requirement in that department.
Engineer: Fair enough.
Operations Engineer: Speaking of legal & privacy, do you/they care about the server logs?
Privacy Officer: I don’t think so. The device id is the most sensitive bit of information we’re handling here and that shouldn’t appear in the logs right? I’ll still talk it over with the other privacy folks in case there’s a timestamp to ip address identification problem.
Operations Engineer: That’s correct.
Engineering Manager: Always good to double check.
Privacy Officer: By the way, what happens to a user’s data when they turn the feature off?
Engineer: … I don’t know. Product Manager didn’t bring it up. I don’t have a mock from him about what should happen there.
Privacy Officer: we should probably figure that out.
Engineer: yeah
Engineering Manager: I look forward to seeing the next draft. I think after you’ve applied the changes & feedback here you should send it out to the public engineering feature list and get some broader feedback.
Engineer: will do. Thanks everyone
Who brought up user data safety & privacy concerns in this conversation?
DBA, Engineering Manager, Privacy Rep.