Difference between revisions of "Facilities I'd like to offer in a later version"

From Alistair Mann / csi18n
Jump to: navigation, search
(Security)
Line 14: Line 14:
 
=== Docker access ===
 
=== Docker access ===
 
Not strictly speaking part of this project, but it would be very interesting to hide servers behind docker-based caching servers.
 
Not strictly speaking part of this project, but it would be very interesting to hide servers behind docker-based caching servers.
 
=== Local servers ===
 
There is just the one server right now. It would be useful to have several around the world, with replication between them, leaving software clients to work out which gives best service.
 
  
 
=== Fixed IP ===
 
=== Fixed IP ===
 
Who knows what the current IP is, or how long it will last? Not me, for sure. DDNS can only take things so far.
 
Who knows what the current IP is, or how long it will last? Not me, for sure. DDNS can only take things so far.
 +
 +
=== IPv6 ===
 +
It's astonishing that IPv6 is still not supported at the consumer level. It ''is'' available from datacentres, so I'd expect to offer IPv6 access as and when service can be provided from such a place.
  
 
=== Local caching ===
 
=== Local caching ===
 
All requests received are routed directly to the origin server. For testing purposes as well as performance reasons, I'd prefer to route traffic first to a local cache,  even a load balancer if warrantied.
 
All requests received are routed directly to the origin server. For testing purposes as well as performance reasons, I'd prefer to route traffic first to a local cache,  even a load balancer if warrantied.
 +
 +
=== Local servers ===
 +
There is just the one server right now. It would be useful to have several around the world, with replication between them, leaving software clients to work out which gives best service.
  
 
=== RFC7230-7 Compliance ===
 
=== RFC7230-7 Compliance ===
 
HTTP/1.1, as used by this service, was defined by [http://www.w3.org/Protocols/rfc2616/rfc2616.html RFC2616]. Since June 2014 it is now defined by [http://tools.ietf.org/html/rfc7230 RFCs7230] thru 7237. I would like to revisit the service to make it comply with those new RFCs.
 
HTTP/1.1, as used by this service, was defined by [http://www.w3.org/Protocols/rfc2616/rfc2616.html RFC2616]. Since June 2014 it is now defined by [http://tools.ietf.org/html/rfc7230 RFCs7230] thru 7237. I would like to revisit the service to make it comply with those new RFCs.
 +
 +
=== Scoreboards ===
 +
It would be of use to form some kind of a ranking system such that interested parties can discover higher-quality uploaders. Or perhaps discover lower-quality uploaders, or both. Similarly, it would be useful for uploaders to see subscribers who best treat them.
  
 
=== Security ===
 
=== Security ===
Line 34: Line 40:
 
** All attacks must be against server B which machine A can reach over a private network
 
** All attacks must be against server B which machine A can reach over a private network
 
** DoS or attacking A doesn't count.
 
** DoS or attacking A doesn't count.
 
=== User scoreboards ===
 
It would be of use to form some kind of a ranking system such that interested parties can discover higher-quality uploaders. Or perhaps discover lower-quality uploaders, or both.
 
  
 
=== User to user contact ===
 
=== User to user contact ===

Revision as of 02:38, 24 November 2014

A wish list of facilities I'd like to add.

Binaries

csi18n currently supports resources with a limited set of text-based mime types, such as text/plain; text/html etc.

It would be useful to store binary types too. Examples:

  • image/png. A specifically created overlay on top of a cartoon could render alternative language text 'as if' it was part of the original.
  • audio/webm. Hear/record/distribute a translation of that TED lecture dialog in your language - no reading skills required of your audience.
  • video/mp4. I could imagine intertitles making use of this, I could imagine public service announcements using it too.
  • application/vnd.ms-powerpoint. Do you use these presentations as a teaching aid? How useful would it be that alternate language versions were available?

With binaries, people would also be able to upload suggested translations of (say) Glaswegian English from video into a voiceover ... which would see the translation with broader acceptance bubble to the top.

Docker access

Not strictly speaking part of this project, but it would be very interesting to hide servers behind docker-based caching servers.

Fixed IP

Who knows what the current IP is, or how long it will last? Not me, for sure. DDNS can only take things so far.

IPv6

It's astonishing that IPv6 is still not supported at the consumer level. It is available from datacentres, so I'd expect to offer IPv6 access as and when service can be provided from such a place.

Local caching

All requests received are routed directly to the origin server. For testing purposes as well as performance reasons, I'd prefer to route traffic first to a local cache, even a load balancer if warrantied.

Local servers

There is just the one server right now. It would be useful to have several around the world, with replication between them, leaving software clients to work out which gives best service.

RFC7230-7 Compliance

HTTP/1.1, as used by this service, was defined by RFC2616. Since June 2014 it is now defined by RFCs7230 thru 7237. I would like to revisit the service to make it comply with those new RFCs.

Scoreboards

It would be of use to form some kind of a ranking system such that interested parties can discover higher-quality uploaders. Or perhaps discover lower-quality uploaders, or both. Similarly, it would be useful for uploaders to see subscribers who best treat them.

Security

Security cannot be taken too seriously. I would commit to:

  • Private analysis. Were there funds to do so, I'd contract someone to Blue Team the existing security. I've done the best I can, but I doubt that's enough. Blue Teaming would happen regularly.
  • Public analysis. Under strict conditions of course I'd offer up a server on a private network that the 3rd parties could Red Team over the Internet. The kind of conditions I'm thinking of include:
    • All attacks must be made from machine A which is available over the Internet
    • All attacks must be against server B which machine A can reach over a private network
    • DoS or attacking A doesn't count.

User to user contact

If one user wants to contact another user, it would be useful to facilitate that. For instance, suppose user X provides consistently good translations into Arabic, and so user Y wants to invites user X to a further project.

Such a service could be a cross between fingering and pseudonymous remailing: user X can elect to expose data or not, and take advantage of the service forwarding a message without revealing Xs contact details; user Y can send a message but does not know more about X than X has chosen to reveal. X can at that point take the approach to some other medium like email, or block Y altogether.

WebSockets

The existing implementation requires client software to specifically poll for updates. An advantage of WebSockets is that change-polling can be shifted to the server, thus saving bandwidth and improving responsiveness.

With WebSocket support, csi18n would provide a more seamless background for realt-time collaborative endeavours.